1. Field of the Invention
This invention relates to the field of computer applications, and, more specifically, to support of Java lightweight devices on set top boxes.
Sun, Sun Microsystems, the Sun logo, Java, Java 3D and all Java-based trademarks and logos are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries. All SPARC trademarks are used under license and are trademarks of SPARC International, Inc. in the United States and other countries. Products bearing SPARC trademarks are based upon an architecture developed by Sun Microsystems, Inc.
2. Background Art
Computer systems with display devices (e.g. screen) generally provide users with ways to move around (i.e. navigate) the display devices. Usually, a display device employs a Graphical User Interface (GUI) to pictorially present to the user objects of possible interest. These screen objects, also known as components, may cause a computer to perform other functions or they may just represent a non-functional simple picture of an object.
One type of object of interest in this specification is the heavyweight component. Heavyweight components are those components that have their own associated native screen resource (commonly known as peer) therefore are registered with the native windowing system (i.e. the underlying engine that controls the GUI). Heavyweight components are opaque and are navigable by any means available for navigation on the computer system. Means of navigation include but are not limited to the use of a pointing device such as a mouse, touching of the object on a touch screen, traversing through the objects by the use of keyboard elements, and remote control means. Navigating through a user interface using keyboard elements such as cursor keys and keypad keys is known as focus navigation. For example, a user can give focus to different heavyweight objects on a display screen by the use of the Tab and Shift Tab keys. An object that has focus is highlighted and is available to receive other keyboard events—the object is said to have event focus. As the user hits the Tab key, a different object is highlighted. However, there could exist windowing objects on the user interface screen that do not highlight when the user navigates by use of the Tab or other keyboard keys. These objects are known as Lightweight components.
Lightweight components are components which do not have native opaque windows (i.e. no structure or peer classes in the native windowing system engine) associated with them, but borrow the screen real estate of a heavyweight ancestor. Unlike heavyweight components, a lightweight component is a screen element that does not need a corresponding peer element in the native layer and thus supports transparencies. These elements typically look the same on different platforms because they are implemented in Java or other device independent language. Since there is no native layer element, the native layer is not necessarily aware of the lightweight element.
In user interfaces where neither a touch screen nor a pointing device is used, users often navigate among objects and activate them using a keyboard or keyboard equivalent. For example, a user may employ a remote control or other non-pointing input device to navigate amongst available objects on a user interface screen. A typical approach employs a “cursor” highlight to indicate the current object (i.e. user interface widget or link) that has focus. Once an object on the display has focus, it is possible to activate/drive the object using further defined keystrokes. For example, using a “select” button or equivalent, the user can initiate an action for the currently highlighted object (i.e. object that has focus).
Using arrow (cursor) keys on a keyboard, remote control, or other device, the user can move the cursor to the “next” object in an up, down, right, or left direction. This works fine with the native (e.g. local platform) windowing system widgets and hyper links. The native windowing system keeps all the information about the native widgets (i.e. heavyweight components). This makes navigation amongst the native widgets seamless. The Java Lightweight Components are widgets which are not visible/accessible to the underlying native windowing system and since Java has no built-in windowing system to manage the Lightweight Components, it is not feasible to navigate around a user interface screen when there are no pointing devices.
In Java, a Lightweight widget gets event focus when the point (i.e. the coordinates on the GUI) of the event is within the boundaries (i.e. geometry) of the widget. A navigation event is delivered to the Heavyweight ancestor widget associated with the Lightweight widget, which in turn dispatches the event to all its components. The Lightweight widget decides if the event occurred within its geometry and if so, grabs it. However, it is difficult to designate the point of a navigation event without a pointing device. Therefore, there is a need for a solution for Lightweight components that is consistent with Native widgets in the navigation models.
Note that the cursor navigation approach described above is typically used in set top boxes and other information “appliances” where it is considered undesirable to provide a mouse or other pointing device. However, the fundamental navigation problem described herein also applies to a PC environment in which the user is navigating via a keyboard mechanism and choosing not to use a mouse.
In all of these cases, an issue to be solved both technically and from the point of view of the user interacting with the system is the question of how to send various windowing events (e.g. commands) to Java Lightweight Components so that they behave like regular windowing System Widgets. For example, there is a need for Lightweight widgets to behave consistently with the regular Windowing System Widgets during navigation (i.e. lightweight components should receive event focus by use of any available navigation method).
Environments such as Motif, Windows, Sun Webmail 3.x, and WebTV provide keyboard navigation schemes that support moving a cursor from one user interface object to another however, these environments do not currently provide good support for Lightweight Components. On desktops, a Lightweight component receives focus when a user performs an event such as clicking in its bounding regions. Native windowing system (Windows/Motif/DWL) forwards this event to native parent container associated with the Lightweight. The container, in turn, dispatches this event to all the Lightweights it contains. Each Lightweight checks whether the event happened in its bounding regions (not necessarily bounding rectangle) and if so, consumes it and claims it.
In most instances, the native containers associated with Lightweights are not FocusTraversable widgets. Focus traversal is the ability to use keystrokes (not the mouse) to traverse components capable of accepting keyboard focus. Those keystrokes are defined to be <Tab> to move forward and <Shift-Tab> to move backward. Once the focus is owned by a component then it should be possible to activate/drive that component with further defined keystrokes (such as <space> to press a Button). It is the responsibility of the component to implement the proper activation once it has focus. A component which is capable of accepting focus in this way should always render some form of visual feedback when it gets focus so that the user can easily see which component has focus as the user traverses using Tab/Shift-Tab. Typically this feedback takes the form of a colored bounding box drawn around the component. The native toolkits on each platform provide varying degrees of support for focus traversal by default. However, explicit support for focus traversal is implemented in the common Java AWT (Advanced Windowing Toolkit) code so that the behavior is more consistent across platforms.
In a set-top box/information appliance environment, where there are no pointing devices provided for user input, there is no way to send focus and focus events to these Java Components. This invention becomes even more crucial for the user's interactions with the product.
Image Maps
The existing solution supports Lightweights being handled as Image maps. Image maps are images in Web pages that include hot regions (i.e., hotspots). An image map in a Web page has three components, an image, a set of map data, and an HTML host entry. The image is a normal Web image, typically stored in the GIF or JPEG format. The map data set is a description of the mapped regions within the image. The host entry is HTML code that positions the image within the Web page and designates the image as having map functionality.
An Image map has a special behavior for the widgets expecting mouse events. A mouse like arrow image is popped up to simulate mouse events for these widgets. The simulation generates mouse down, up, click, move and drag events. The arrow movement is very slow and makes the user interface (UI) inconsistent with the rest of the UI model for a Set Top Box. In the existing solution, a native widget associated with Lightweight(s) is made focusTraversable and is handled like an Imagemap, thereby simulating mouse events. This causes undesirable problems in the User Interface model.
For example, in the prior art the Native container associated with a Lightweight is considered to be an imagemap therefore all the Components contained in this Container are handled like an imagemap. This is the case even if the other components are not expecting mouse events and hence should not be considered as imagemap. Handling of Lightweights as imagemaps lead to undesirable User Interface models that significantly slow down user interaction such as requiring unnecessarily complex user operations to accomplish a simple navigation task.
Also, a Lightweight component implementing any of the P-Java specific Interfaces such as NoInputPreferred, and KeyboardInputPreferred may never get focus events when the Lightweight component is treated as an imagemap. This is because the native windowing System does not know anything about the Lightweights. This leads to inconsistency between Java-Native widgets and the Lightweights.